Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Thanks for the PR! I'm personally somewhat wary to do this though because these restrictions are enforced by crates.io, not Cargo, so what happens if crates.io changes? It could take quite some time before Cargo is updated to align with the new changes.

I think that there was also a lot of discussion about perhaps sharing dependencies, but IIRC that never really reached a conclusion?

Thanks for the PR!

👍

I'm personally somewhat wary to do this though because these restrictions are enforced by crates.io, not Cargo, so what happens if crates.io changes? It could take quite some time before Cargo is updated to align with the new changes.

Mmm. Would a better approach maybe include a test upload to crates.io? (Although this would introduce a new point of spurious failures for CI builds trying to cargo publish --dry-run...)

I think that there was also a lot of discussion about perhaps sharing dependencies, but IIRC that never really reached a conclusion?

rust-lang/crates-io-cargo-teams#41 had some discussion about possibly sharing dependencies, but the answer for a lot of the metadata in there seemed to be "nope, this can't be easily shared", and some uncertainty as to how much value there actually is to sharing what can be shared.

I'm also not sure if it's worth the engineering time to fix many of the more minor/trivial metadata issues listed there, when you can simply modify the Cargo.toml and resubmit. Features specifically seem to be the reoccuring (initial motivation for both linked issues), less trivial (changes to source code, build scripts, and possibly already published code generators) footgun. Adding a shared dependency to fix just features seems even less worthwhile.

That said, I could easily be missing some context here - and test uploads would moot all of this.

I'm personally a fan of the "dry run publish" endpoint on crates.io, although that would require coordination from crates.io and likely more implementation work than this.

In general though @ehuss has done a lot of categorization work on rust-lang/crates-io-cargo-teams#41 and I think that it's not quite at a point where we can commit one way or another to this solution.

Closing this PR for now, I'll mention the dry run publish endpoint idea in rust-lang/crates-io-cargo-teams#41 .